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ABSTRACT 

The Portable Courseware Project (PORTCO) of the U.S. 
Department of Defense (DoD) is typical of projects worldwide that 
require standard software interfaces. This paper articulates the 
strategy whereby the federal multimedia courseware initiative 
leverages the open syste*TiS movement and the new realities of 
information technology. The federal strategy is to facilitate the 
creation of an environment in which high quality portable courseware 
is available as commercial off-the-shelf products and is 
competitively supplied by vendors. The Request for Architecture 
developed cooperatively by DoD and the National Institute of 
Standards and Technology (NIST) will generate a portable courseware 
system architecture incorporating standards which meet users' needs. 
A computer-based interactive training applications profile must be 
developed which ^ along with the system architecture , will provide the 
basis for identifying needed standards. NIST will then accelerate the 
development of these standards through established standards forums. 
Five appendices provide information on Open System Environments # the 
Applications Portability Profile, the National Computer Systems 
Laboratory (NCSL) Technical Program, Key Multimedia Courseware 
Project Dates, and the Request for Architecture. (DB) 
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EXECUTIVE SUMMARY* 



The federal government and other U.S. organizations are about to invest billions of 
dollars to develop multimedia training materials for delivery on computer-based inter- 
active training systems. Acquisition of a variety of computers and peripheral devices 
hosting various operating systems and suites of authoring system software will be 
necessary to accommodate the widely varying requirements of this courseware. There 
is no single source that will satisfy all needs. Although high-performance, low-cost in- 
teractive training hardware is available, the products have proprietary software inter- 
faces. Because the interfaces are proprietary, expensive reprogramming is usually re- 
quired to adapt such software products to other platforms. This costly reprogramming 
could be eliminated by adopting standard software interfaces. 

DoD's Portable Courseware Project (PORTCO) is typical of projects world-wide that 
require standard software interfaces. This paper articulates the strategy whereby the 
Federal multimedia courseware initiative leverages the open systems movement and the 
new realities of information technology. TTiese realities encompass changes in the pace 
at which new technology becomes available, changes in organizational goals and 
philosophy, new roles of vendors and users, changes in the procurement process, and 
acceleration towards open system environments. The Federal strategy is applicable to 
all projects and systems which require open systems to achieve mission objectives. 

The PORTCO goal is to facilitate the creation of an environment in which high quality 
portable courseware is available as commercial off-the-shelf products and is competi- 
tively supplied by a variety of vendors. In order to achieve this goal, a system architecture 
incorporating standards to meet the users' needs must be estrblished. The Request for 
Architecture (RFA) developed cooperatively by DoD and the National Institute of 
Standards and Technology (NIST) will generate the PORTCO systems architecture. 
This architecture must freely integrate the courseware and authoring software from the 
lower levels of machine architecture and systems service implementation. In addition, 
the systems architecture will establish how the application-specific technologies relate 
to other technologies. Further, a computer-based interactive training applications 
profile must be developed. This profile, along with the systems architecture derived as 
a result of the RFA, provides the basis for identifying the needed standards. NIST will 
then accelerate the development of these standards using, but not restricted to, existing 
standards activities within established standards forums. 

The Federal multimedia courseware effort has adopted the Interactive Video Industry 
Association (IVIA) Recommended Practices for Interactive Video Portability as the 
baseline for the migration of computer-based interactive training systems to an open 
systems environment based upon international standards. The Federal strategy includes 
an evolutionary migration to standards-based. Open Systems Environments (OSE). An 
important aspect of this migration strategy is to move to open systems via step-wise 
evolution rather than via quantum leaps. 

Another area of concern is that of infrastructure issues, such as maintaining and support- 
ing the technologies required for computer-based interactive training. The Federal 
multimedia courseware initiative will use the RFA-based architecture to differentiate 
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between those technologies that can be maintained and supported by existing infrastruc- 
ture mechanisms and those that require new mechanisms. Existing infrastructure 
mechanisms will be used and where infrastructure mechanisms do not exist, the approach 
will be to place high priority on establishing the appropriate mechanisms. Establishing 
an infrastructure mechanism is a non-trivial task requiring sustained investment of 
resources. 



* The mention of commercial products in this paper is to describe the research environ- 
ment and does not imply recommendation or endorsement by the National Institute of 
Standards and Technology. 
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BACKGROUND 



Introduction 

Over the next several years the federal government and other U.S. organizations will 
invest billions of dollars to develop training materials for delivery on computer-based 
interactive training systems. As part of this investment, these organizations will acquire 
a variety of computers and peripheral devices. This hardware will host a variety of 
operating system software and a suite of authoring system software in order to accom- 
modate the widely varying requirements of courseware development. No single source 
will satisfy all needs. 

Several commercial manufacturers currently offer high-performance, low-cost interac- 
tive training hardware, but they bundle their products with proprietary software inter- 
faces. Vendors of integrated systems bundle their products with sophisticated interfaces 
to all system resources, while vendors of individual peripherals (such as mice) bundle 
their products with simpler interfaces to control their solitary device. Because these 
interfaces are proprietary, courseware and authoring softivare written to operate on one 
product will not run on a competitor's equipment. Expensive reprogramiming is usually 
required to adapt such software products to new peripheral hardware. These reprogram- 
ming costs will be eliminated by adopting standard software interfaces to shield cour- 
seware and authoring software when training system hardware components are replaced 
by new ones. 

The Portable Courseware Project (PORTCO) is typical of projects within the DoD and 
other federal agencies that recognize the need for standard software interfaces. In fact, 
the vast majority of PORTCO software interface requirements are shared across a broad 
spectrum of other applications within the U.5. federal government. Farther, this require- 
ment for standard software interfaces is not limited to the U.S. federal sector. Users 
world-wide have begun to recognize the importance of establishing standard software 
interfaces as a strategic element of information technology planning. 

The world-wide effort by users to establish standard software interfaces has caused a 
fundamental change in the information technolog) industry. There are several aspects 
of this change that are particularly important to projv'jcts such as PORTCO. Perhaps the 
most important of these aspects is the movement away from proprietary products toward 
products based on open system concepts. 

The Federal strategy for multimedia courseware leverages the open system movement 
and the new realities of information technology. These realities encompass changes in 
the pace at which new technology becomes available, changes in organizational goals 
and philosophy, new roles of vendors and users, changes ii? the procurement process, 
and acceleration towards open system environments. While specifically oriented towards 
Federal computer-based interactive training systems such as PORTCO, the Federal 
strategy is equally applicable to other projects and systems that require open systems to 
achieve mission objectives. 
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The Environment 

Federal agencies are under increasing pressure to use information technology to improve 
efficiency and effectiveness in carrying out assigned missions. At the same time federal 
agencies are struggling with finding ways to use information technology to improve 
efficiency and effectiveness; there is a new reality that is becoming increasingly evident. 
Key aspects of this new reality are that federal agencies 

• now recognize that they no longer can create de facto standards and impose 
them on the commercial market; 

• need to rely on the commercial market for information technology products 
and services; and 

• must establish strategies and plans for acquiring information technology 
products and v^ervices based upon open system standards which support ap- 
pUcations software portability and interoperability. 

The environment within federal agencies is changing. Whereas before there were 
isolated islands of computing, now there is interdependence of users across the entire 
organization. This interdependence has served to highlight enterprise-wide needs for 
common application and system architectures, communication networks, and databases. 
This interdependence has also raised concerns about infrastructure issues such as 
maintenance and support of these enterprise-wide resources. These issues are particular- 
ly troubling because although the requirement for infrastructure services is increasing, 
the resources available to support these services are decreasing. As part of the new 
reality, federal agencies must address infrastructure issues from poUcy, management, 
and technical perspectives. 
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A1AJ0R CONCEPTS 



Open System Environment 

One of the biggest factors underlying the open system movement is that users now 
recognize that no single vendor can supply all of their needs for information technology 
systems and services. Since homogeneity is no lon,^er practical, users need open systems 
that provide interoperability of products and portability of people, data, and applications 
across heterogenous computing environments. 

This need to improve portability and interoperability has resulted in widespread interest 
in standards such as POSIX (Portable Operatir { System Interface for Computer En- 
vironments) and GOSIP (Government Open Systems Interconnection Profile). While 
important milestones in the effort to achieve portability and interoperability, POSIX and 
GOSIP are not sufficient to address the full spectrum of needs. 

A more comprehensive approach is needed to achieve an Open System Environment 
(OSE) that integrates POSIX with GOSIP and provides additional functionality to 
accommodate the broad range of application requirements. An OSE is a key aspect of 
a worldwide movement in which the U.S. federal government and other information 
intensive organizations are working to 

• protect their investment in appUcations software, 

• reduce dependence on single sources of supply for information technology 
products and services, 

• stimulate the availability and quality of products in the commercial 
marketplace, and 

• provide a stable base for the evolutionary development of large, complex sys- 
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The OSE movement is an outgrowth of efforts to estabHsh the groundwork for computing 
environments that 

• are based upon an architectural framework that allows an extensible collec- 
tion of capabilities to be defined, 

• define their capabilities in terms of non-proprietary specifications available 
to any vendor for use in developing conmiercial products, and 

• control their evolution by a consensus-based process for decisions regarding 
capability definitions, specifications, and other issues related to the comput- 
ing environment. 

Computing environments having the above characteristics are referred to as "open." The 
developers of the concept of open computing were concerned primarily with inter- 
operability of computers communicating over a network. The technology that resulted 
from their work is conunojily referred to as Open Systems Interconnection (OSI). 

An OSE extends the OSI concept to the broader problems of applications portability 
and interoperability. Efforts are currently underway by both vendors and users to 

• establish an architectural framework for an OSE; 

• define OSE interfaces, protocols, services and supporting formats; and 

• provide a fomm for consensus-based agreements on OSE issues. 

Although the OSE concept is relatively new, the concept has matured to the point where 
there is an emerging international consensus on the functionality (i.e., the collection of 
interfaces, protocols, services and supporting formats) that should be included in an 
OSE. Additional information regarding the OSE concept is presented in Appendix A. 

The OSE effort has not, however, matured to the stage where there is international 
agreement on the suite of specifications for the OSE functions. In the absence of an 
agreement, organizations have used a variety of schemes to select their own specifica- 
tions to define OSE functions. These schemes result in a suite of specifications called 
OSE Profiles. These OSE Profiles typically reflect 

• the functions that are required by the applications of interest, 

• the organization's view of the viability of a particular specification for migra- 
tion to an international standard when that standard is established, and 

• the availability of commercial off-the-shelf products that conform to the 
specifications. 

The Applications Portability Profile (AFP), developed at the National Institute of 
Standards and Technology, is an OSE Profile developed for use by U.S. federal agencies. 
The OSE functions included as part of the APP are those that have been identified as 
important to a broad spectrun of U.S. federal agencies. 

The APP is defined in terms of open system specifications organized into major service 
categories. These service categories, along with examples of the specific services in each 
category, are shown in Appendix B. 

to 
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The APP provides a conceptual framework for a federal agency to develop application 
profiles that reflect their particular needs. Application profiles are useful to gain an 
understanding of open system requirements and to identify targets of opportunity for 
implementing open system standards. The APP and application profiles play com- 
plementary roles in federal agency information technology plans. 

Multimedia Technology 

Multimedia is an example of a trendy term used in the computing arena. As is the case 
with most such terms, it hints at substantive notions that are widely used but not well 
defined. In this case, the term miiltimedia builds on traditional notions of integrating 
different data objects (e.g., text, graphics, and numerics) into a single higher level object 
(e.g., a document). This holistic view of the integration of disparate elements is the theme 
that is common to the style of computing exemplified by multimedia. The notion of a 
reference model or architecture that establishes the integrating framework is central to 
this style of computing. The current interest in multimedia technology is primarily 
centered on the following: 

• data objects, 

• storage and transport, 

• operating environments, and 

• applications. 

One dimension of the current interest in multimedia is the focus on data objects such as 
digital video and audio. There are two aspects of this focus. The first deals with the 
method for encoding the digital representation of the data. Previously, interest in data 
encodrng dealt primarily with presentation issues such as the fidelity of the image and 
the sound. Currently, interest in data encoding has been expanded to irdude concerns 
regarding the information content of the digital representation to support analysis, 
editing, and manipulation. Data compression/decompression techniques that preserve 
both presentation fidelity and information content are particularly important. The 
second focus of the current interest in multimedia data objects is interactivity. The 
traditional environment supports dealing with data objects such as text, video, and audio 
in terms of batch-like operations; e.g., reading a book, viewing a movie, or listening to a 
recording. The key here is that th^re is an implied order that characterizes the operations. 
This is in contrast to an environment that supports interactive operations that deal with 
data objects in random order; e.g., nonlinear browsing, processes in which external inputs 
determine what is viewed or heard. Interactivity places additional requirements on data 
compression/decompression in that both compression and decompression must be done 
on-the-fly. 

Another area in which data compression/decompression is important is in the storage 
and transport of the multimedia data objects. Data compression/decompression algo- 
rithms will play a large role in opdmizing the use of storage capacity and network 
bandwidth. Videodisc is frequently used as a medium to store digital video and audio 
data. CD-ROM can also be used to store digital video and audio data. Because of the 
differing perspectives from which these media are viewed, gratuitous differences have 
evolved in their respective storage techniques. These differences result in incom- 
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patibilities that severely impact the ability of applications written for CD-ROM to 
operate on videodisc and vice versa. The recent focus on the storage of multimedia data 
objects is gradually shifting to the transport of multimedia data objects over local and 
widearea networks. Broadband ISDN (Integrated Services Digital Networks) appears to 
be the current transport mechanism of choice. Ultimately, systems supporting multi- 
media applications will have to provide a continuum of storage and transport 
mechanisms along with facilities to support interchange of multimedia Jata objects. 

The promise of multim.edia bring.s with it a variety of exotic scenarios in which our ability 
to receive, process, and interact with information is significantly enhanced. Applications 
required to support these scenarios can be viewed as a continuum that includes 

• entertainment, 

• education, 

• training, 

• presentation, and 

• information access, 

The current market for applications in this continuum is dominated by vendors from 
both the computing and entertaimnent industries. Computing is becoming a plug and 
play industry. One expects to be able to "configure" one's computer with different 
components obtained from a variety of sources. Entertainment tends to be a black box 
industry. One buys a television set, not speakers, tuner and monitor as separate devices. 
Each industry has a stake in multimedia and each has contributed to the current interest 
in multimedia. The problem is thai manufacturers in the two industries have entirely 
different perspectives on how systems are put together, and what degrees of freedom are 
available for users to customize their systems. 

There are two main operating environments contending for multimedia applications: 
workstation operating systems such as Unix, and PC operating systems such as MS/DOS. 
MS/DOS was designed as an operating environment to support low-end applications and 
minimal functionality platforms. MS/DOS applications tend to be of the single user, 
stand-alone variety. Although MS/DOS platforms are configurable, the range of choices 
for customizing these platforms is relatively limited. Because the environment is of 
limited complexity, MS/DOS users are expected to be able to operate (i.e., run applica- 
tions and perform administration functions such as file back-up) with little, if any, 
assistance. Unix, on the other hand, was designed to support a much more complex 
situation in which 

• there is a mix of low-end and high-end applications operating concurrently, 

• there are multiple users being served by the same system, and in some cases 
by the same application, 

• the system is typically several heterogenous platforms linked via a network, 

• applications are designed to be interoperable with other applications, and 
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• there is a large range of choices regarding the manner in which a system can 
be configured and customized. 

Because the Unix environment is relatively complex, users typically require technical 
assistance, primarily from "system administrators" who take care of the administrative 
functions which arise in a multi-user, networked environment. The Unix and MS/DOS 
enviromnents should not be viewed as competitors for multimedia applications in that 
each serves a unique, special user need. The two environments collectively provide the 
capability to serve a broad spectrum of current and future multimedia applications. 

The Standards Process 

Standards are documents that set forth requirements, methods of measurement, perfor- 
mance characteristics, and specifications to provide for uniformity of products or ser- 
vices. The standards process can be described in terms of the major types of activities 
shown in the figure below. 

Standards identification starts with the realization that there are benefits to leveraging 
the commonality of requirements that exists among a broad community of users. A 
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Tlie Standards Process 



primary output of this activity is an application profile that identifies 

• the standards that are needed, 

• how the standards relate to each other, 

• which standards already exist, and 

• which standards need to be defined. 

Ideally this activity should begin at the time a new application is first being defined. In 
this way, standards can be built into the evolution strategy for the application and the 
importance of accelerating particular standards becomes apparent. 
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Typically, the requirements for several different standards are likely to be identified. 
These standards will each be in a different stage of maturity. Some will be well defined 
with conformance tests and test laboratories providing ce/tification for products that 
adhere to the standards. Others may exist as standards, but not yet have any conformance 
tests. Still oth«r standards may have already been identified by others and are being 
developed by the standards community. Finally ^ome standards may not yet have been 
identified. 

Standards development is conducted by some 400 U.S. organizations, each of which 
operates under its own rules. Formal U.S. standards are normally designated as 
American National Standards and are developed under criteria meeting the require- 
ments of the American National Standards Institute (ANSI). These criteria relate to the 
following concepts. 

Op^n Participation All parties with an interest that may be affected by the proposed 
standard shall have reasonable opportunity to participate in its development or to submit 
comments covering its provisions. 

Balance of Interest The membership of the standards developing body must be so 
constituted that no single interest shall have a disproportionate share of influence in the 
content of the document or in its approval. (Interests are categorized based on the subject 
matter of the standard. For example, such interests may be users, producers, installers, 
general interests, and government). 

Cnmment Resolution All individual comments received on the content of the standard 
shall be addressed and a reasonable attempt shall be made to resolve the comment. 

C oordination All efforts shall be made to avoid conflict with the provisions of exisMng 
standards or with standards being developed by other organizations. To this end, formal 
liaison with other organizations is encouraged. 

Consensus Adoption of a standard is dependent upon achieving a consensus of con- 
cerned interests. A substantial voting majority on a ballot may not be responsive to this 
requirement, particularly if one category of interest is substantially opposed to its 
adoption. 

The strategic focus of standards development is to accelerate the process. The time 
required to develop a particular standard will vary greatly depending on the degree of 
consensus that has been achieved for the standard, the maturity of the technology 
associated with the standard, and the overall requirements of applications expected to 
use the standard. An effective way to accelerate the standards development process is to 
develop tools that support implementations of the standard. Examples of tools are tests, 
feasibility demonstrations, prototypes and procedure toolkits. Another way to accelerate 
standards development is through workshops that demonstrate an interest in the field 
and provide preliminary work towards consensus. Workshops also provide a forum to 
obtain important input from organizations that are not directly participating in the 
standards development process. 

Standards implementation takes place as a result of decisions by 
• users to apply the standards in procurement, and 
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• vendors to incorporate the standards into their products. 

A decision to apply the standard in procurement is important to establish a marketplace 
demand for the standard; a decision to incorporate the standard into commercial 
products complements the marketplace demand by establishing sources of supply. 
Unless these two complementary decisions are made in the same relative time-frame, 
the standards development effort is essentially wasted. 

Conformance testing activities are directed toward measuring the extent to which an 
implementation (i.e. a vendor's product) adheres to the specifications set forth by a 
standard. The ability to measure conformance is important to assure that a claim that a 
product conforms to a standard has some basis in fact. It is usually not possible or 
necessary to devise a test to determine total (i.e. 100%) conformance. It is, however, 
necessary to obtain agreement between users and vendors regarding the tests that will 
be used to measure conformance. Increasingly, establishing agreements regarding con- 
formance tests is being dealt with as a consensus process within the formal standards 
arena. 

The formal standards process is by necessity, very slow. Progress toward such standards 
is typically measured in years. In spite of the urgent need for standards to support 
multimedia courseware in an open systems enviroimient, federal agencies and other 
organizations must establish a strategy for dealing with situations in which formal 
standards are not available. Part of this strategy must include a means for migrating to 
the formal standards as they become available. 

Migration 

Few organizations are able to fully exploit the benefits of an OSE. First of all, it is not 
currently possible for an organization to obtain an OSE with the functionality described 
in the APP (Applications Portability Profile) and which meets the criteria for "openness." 
More importantly, eveii if it were possible to obtain an open system with all of the 
necessary functionality, pragmatic considerations such as 

• the availability of an adequate budget, 

• the availability of appropriately trained staff, and 

• the need to protect the current investment in information technology 

mitigate against immediately replacing a proprietary system v/ith an OSE conforming 
system. 

Organizations should adopt a strategy that allows them to migrate to an OSE conforming 
system. This migration strategy should be based upon an evolutionary approach in which 
the computing environment evolves as step-wise refinements 

• from an established baseline configuration, 

• through a current target configuration, 

• toward an objective configuration. 

These are illustrated in the figure below and are defined as follows. 
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The Baseline Configuration defines "where we are now." It is comprised of an 
organization's existing information, programs, policies, standards, procedures, 
tielded information systems, and their interrelationships. It reflects what an or- 
ganization currently relies on to accomplish its mission and functions. 

The Current Target Configuration provides a statement regarding "where we are 
going" in the near-term. This configuration reflects an organization's pragmatic 
assessment of what can reasonably be achieved now in moving towards the objective 
configuration. 

The Objective Configuration provides a vision of "where we should be" in the long- 
term. This configuratioi documents an organization's information requirements 
based on mission and functions, and the support and services needed to satisfy those 
requirements. It provides an objective for planning purposes and is not restricted by 
resource availability; in fact, there is recognition that there are technology, resource, 
and other obstacles that prevent attainment of the objective. 

This type of migration strategy embodies an approach which is a departure from the 
traditional "completely-specify-then-build" approach. This new approach recognizes 
that specifications based upon complete and rigorous analysis of requirements is impos- 




Migration Framework 



sible in an environment in which 

• requirements are driven by user-needs, and 

• user-needs evolve as technology improves and experience accrues. 

Infrastructure Issues 

One of the distinguishing characteristics of computer-based interactive training and 
other multimedia applications is the need to integrate several disparate technologies into 
a unified systems framework. This systems framework provides a context for user 
requirements and standards specification. The framework also provides a context for 
understanding how the disparate technologies relate to each other. The figure below 
illustrates the relationship that should exist between 

• a particular class of applications, 

• an application domain in which related applications classes reside, and 
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• a computing environment capable of supporting a variety of application 
domains. 

The lowest level represents those technologies required by almost all appUcations. 
Examples include technologies associated with operating system services such as I/O, 
commands and utilities, etc. The next level represents tailoring (typically special exten- 
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sions or options) of those lower level technologies that is required by a particular 
applications domain. Examples of technologies that are tailored include data manage- 
ment, data interchange, user interface, and graphics. The top level represents those 
technologies required by a specific class of applications. Examples of technologies at this 
level are synchronized audio and motion video. 

These relationships among the various technologies provide a basis for a strategy to deal 
with the infrastructure issues of maintaining and supporting the technologies within the 
unified framework. The strategy requires a way, preferably an application profile, to 
identify how the appHcation requirements are distributed among the three layers of the 
model. The requirements that necessitate application-specific technologies should 
receive the highest degree of concern regarding maintenance and support. 

The goal to minimize the cost to a user organization for maintenance and support of 
appHcation specific technologies suggests the following basic strategy: 

• minimize the requirement for application jpecific technologies by utilizing, 
to the maximum extent practical, domain-specific, and/or base-level tech- 
nologies, 

• share maintenance and support costs with other current and/or potential 
users of the application-specific technologies, and 

• migrate application-specific technologies to the domain-specific and/or base- 
level technologies. 
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THE FEDERAL STRATEGY 



Introduction 

The Federal goal is to facilitate the creation of an environment in which high quality 
portable courseware 

• is available as commercial off-the-shelf products, and 

f> is competitively supplied by a variety of vendors. 

The Federal strategy leverages the worldwide open systems movement. Key elements 
of this strategy include: 

• establishing a system architecture that provides the context for user require- 
ments and standards specification. 

• developing a plan to identify and accelerate the development of the required 
open system standards. 

• developing a plan for an evolutionary migration to a standards based open 
system environment. 

• the use of application profiles to 

gain an understanding of open system requirements; and 
identify targets of opportunity for implementing open system 
standards. 

• leveraging existing open system activities by 

implementing existing open system standards rather than 
developing its own standards; and 

maintaining a collaborative partnership with NIST and other 
organizations involved in the development and promulgation of 
open system standards. 

Systems Architecture 

The Request for Architecture (RFA) developed cooperatively by DoD and NIST will 
extend the current multimedia portable courseware systems architecture. This architec- 
ture will isolate the courseware and authoring software from tlie lower levels of machine 
architecture and systems service implementation. This notion of isolating lower level 
detail from higher level functions is the conceptual basis which underlies software 
portability. In addition, the system architecture will establish how the application- 
specific technologies relate to other technologies (i.e., domain-specific and base-level) 
required to achieve the objectives. 

Standards Development 

The standards strategy has three major dimensions: 

• identifying areas that could benefit from standardization, 

• accelerating the development of the identified standards, and 
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• providing a mechanism to operate during the period in which needed stand- 
ards are not available. 

A computer-based interactive training applications profile v/ill be developed. This 
profile, along with the systems architecture derived as a result of the RFA, will provide 
the basis for identifying the needed standards. As the needed standards are identified, 
NIST will establish a plan for accelerating the development of these standards. To the 
extent practical, the plans will leverage existing standards activities within established 
standards forums. 

Because the formal standards process cannot be expected to keep pace with the need for 
standards, the plans will not be restricted to the use of formal standards organizations. 
There are several vendor-sponsored consortia (e.g., X/Open, Corporation for Open 
Systems (COS), Unix International (UI), and the Open Software Foundation (OSF)) 
that have complementary roles in establishing informal OSE standards. Properly util- 
ized, these informal consortia standards can serve an important role in accelerating the 
adoption of formal voluntary international standards. Leveraging these consortia stand- 
ards to produce voluntary international standards has the added benefit of accelerating 
the availability of conmiercial products which incorporate those standards. 

Consortia standards are particularly well suited to jse as a basis for international 
voluntary OSE standards because each consortium has 

• a vested interest in having its standards adopted as voluntary international 
standards, 

• consensus based processes for reaching agreements among their members, 
and 

• a world-wide membership that includes every major supplier of OSE 
products. 

These consortia standards will also be used as interim standards in those cases where 
international voluntary standards are not available or are not appropriate for OSE. Use 
of consortia standards as interim standards will stimulate the market for OSE products 
by creating a market demand and by reducing the risks for vendors to produce compliant 
products. 

Migration 

The Federal multimedia courseware initiative has adopted the "IVIA Recommended 
Practices for Interactive Video Portability" as the baseline for the migration of computer- 
based interactive training systems to an open systems environment based upon interna- 
tional standards. The Federal strategy includes an evolutionary migration to a standards- 
based, OSE. An important aspect of this migration strategy is to keep up with the open 
systems movement via step-wise evolution rather than catch up with the open system 
movement via quantum leaps. Other aspects of this strategy should include 

• identifying targets of opportunity for implementing open systems standards, 

• developing a mechanism for planning the migration of the identified targets, 
and 
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• managing the migration as a long range process of step-wise refinements 
toward the desired open system objective. 

Part of the effort is to develop a plan that describes the process by which the transition 
from the baseline configuration through the current target configuration toward the 
objective configuration will proceed. In particular, this plan will describe how the target 
conHguration is to be periodically adjusted closer to the objective configuration to reflect 
evolutionary changes in mission, policy, technology, and user requirements. In addition, 
this plan will describe how the migration will be managed in a manner that 

• protects the investment in the basehne configuration, 

• minimizes the disruptions to current operations, 

• recognizes the reality of Umits imposed by available resources, and 

• provides flexibility to accommodate local requirements. 
Infrastructure 

The Federal strategy also deals with the infrastructure issues of maintaining and support- 
ing the technologies required for computer-based interactive training. The Federal 
multimedia courseware will use the RFA-based architecture to differentiate between 
those technologies that can be maintained and supported by existing infrastructure 
mechanisms, and those that will require new mechanisms to provide the required 
maintenance and support. Whc^re infrastructure mechanisms exist, the approach will 
contribute to those mechanisms to the extent necessary to ensure that Federal users' 
needs are addressed. Where infrastructure mechanisms do not exist, the approach will 
place high priority on establishing the appropriate mechanisms. Establishing an in- 
frastructure mechanism is a non-trivial task. It requires sustained investment of resources 
over a long period of time. The time period required depends upon how long it takes to 
get an appropriate mechanism established and nurtured to the point that it can be 
"passed-off' to an appropriate recipient. Determining what mechanism is appropriate 
and who is an appropriate recipient are key aspects of the infrastructure issue. 
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NISrS ROLE 

Overview 

The mission of the National Computer Systems Laboratory (NCSL) of the National 
Institute of Standards and Technology (NIST) is to 

• increase productivity in government and the private sector, and 

• contribute to the posture of U.S. industry in the international marketplace. 
We do this by 

• developing standards and guidelines for computer and related telecom- 
munications systems, 

• providing technical assistance to federal agencies, and 

• conducting supporting research in computer science. 
We work with the broad spectrum of 

• private sector computer users; 

• computer vendors and service providers; 

• professional, academic, and research communities; 

• international and national voluntary standards groups; and 

• managers and users within federal, state, and local governments. 

Part of the "value added" of our involvement is that we are aware of what is going on 
throughout these diverse communities. Further, we are recognized as an objective third 
party in building a consensus on issues, such as standards, that impact all of these 
communities. 

A primary focus of the NIST mission is technology transfer. We try to thoroughly 
understand the technology and the problems users experience in attempting to use that 
technology. We try to find solutions to these problems and then package those solutions 
in a form that meets the needs of those who have the problems. The products and services 
shown below are the ways in which we currently package solutions. 

• Federal Information Processing Standards and Guidelines 

• Special Publications and other Technical Reports 

• Reimbursable Assistance to Federal Agencies 

• Newsletter and Bulletin Boards 

• Conferences and Workshops 

While there is a federal flavor in our activities, we make a concerted effort at outreach 
to users in the private sector. Our view is that the problems federal and private-sector 
users face are essentially the same. Our activities are 
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• laboratory based, 

• cooperative, not regulatory, 

• targeted to areas of biggest payoffs, and 

• forward looking, covering areas of new technology. 

These activities are directed toward helping users become informed consumers of 
information system products and sc vices available in the commercial marketplace. Our 
lab-based envir nment allows us to develop guidance that helps federal agencies and 
others reduce the risks of incorporating new technology into their operations. Our 
technical program is focused on "open systems," with particular emphasis on 

• software portability and interoperability, 

• information interchange, 

• compatibility and interoperability of systems interconnected through net- 
works, and 

• computer security. 

NIST attempts to maintain a delicate balance between meeting urgent federal needs for 
open system standards and the consensus process that lies at the heart of the national 
and international standards process. There are clearly risks associated with attempting 
to balance such competing interests. To mitigate against these risks, NIST has established 
collaborative partnerships with 

• the standards community, 

• state and local governments, 

• vendors and vendor-sponsored groups, 

• private sector users, and 

• other regional/national governments. 

Key to the effectiveness of these collaborative partnerships is close communications to 
assure that each group is acting on the most up-to-date information regarding common 
goals. Collaborative partnerships also provide the means for building the consensus 
necessary to achieve woridwide acceptance of and commitment to open system environ- 
ments which facilitate portability, interoperability, and scalability. 
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The Multimedia Courseware Project 

NIST is currently engaged in standards identification efforts, primarily focusing on 
standards that support multimedia courseware in an open systems environment. This 
effort is part of the Multimedia Courseware Project Plan (see Appendix D) and builds 
on earlier efforts to 

• broaden our understanding of multimedia technolo©r, particularly as it ap- 
plies to computer-based interactive training applications; 

• investigate how the ongoing NIST technical activities could be leveraged to 
support PORTCO and related projects (see Appendix C); 

• establish an in-house technical team as a focal point for multimedia and re- 
lated computer-based interactive training activities; 

• establish visibility and support for the U.S. federal multimedia and related 
computer-based interactive training efforts; 

• identify and establish contact with the major players in the multimedia and 
related computer-based interactive training community; and 

• identify standards opportunities that could be leveraged to advance the mul- 
timedia and related comouter-based training efforl^. 

Based upon these earlier efforts, we believe that there are 

• several existing standards that could form the basis for a computer-based 
training application profile based upon a more general multimedia specific- 
domain, 

• a minimum of two operating environments in which multimedia applications 
run under, and 

• a proposal that we believe fills in a necessary gap. 

The existing standards are POSIX, GOSIP, and XWindows. The two environments are 
MS/DOS and an OSE-based environment such as Unix. The proposal is the "IVIA 
Recommended Practices." 

Our current efforts will iikely result in a dual-platform multimedia courseware strategy: 
one oriented around the MS/DOS operating system and the other around an OSE-based 
operating system. Maintaining compatibility with the MS/DOS operating system en- 
vironment is simply pragmatic recognition of the key role MS/DOS has in the current 
multimedia courseware arena. Even more important, identifying the MS/DOS operating 
system as a strategic component of our multimedia courseware strategy reflects our view 
that MS/DOS 

• uniquely addresses user needs for an operating system to support low-end 
applications and minimal functionality platforms, 

• will continue to be a strategic element of desktop computing for the foresee- 
able future. 
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• will benefit from technology advances, particularly with regard to user inter- 
face and device-independent technologies, and 

• will evolve so as to eventually embody many of the characteristics of an OSE- 
based operating system. 

A key aspect of our standards identification effort is to use the RFA to solicit from all 
interested varties ideas for a multimedia architecture. We will use the "IVIA Recom- 
mended Practices" as a baseline. This process has already started with announcements 
in the rnmmerce Business Daily and the Federal Register . We will also use the Open 
Solftware Foundation and Interactive Video Industry Ar'^ociation to distribute the RFA 
directly to their respective members. The RFA is presented in Appendix E. 

In support of these efforts we are developing plans to evolve our current electronic 
publishing laboratory into a multimedia systems laboratory. This is a natural evolution 
because electronic publishing is evolving to multimedia pubUshing where pubUshed 
materials (courseware, electronic documents, recordings, etc.) are no longer limited to 
one medium (the printed word, video, audio, bit mapped images, video) but are repre- 
sented as the integration of a variety of media. The laboratory will be used to study the 
integration of the different media and related technologies required to support multi- 
media courseware in an open systems environment. 

The laboratory will also serve as a facility to demonstrate the integration of multimedia 
technologies, as well as a facility to support conformance and interoperability testing. As 
is the case with other NCSL laboratories, we actively solicit industry support and 
participation in the multimedia laboratory. This industry support can be provided by 
loaning equipment and people to work directly with us through one of the many the 
existing NIST/Industry cooperation mechanisms. 

NIST will have to closely track the numerous standards and related activities that impact 
multimedia courseware and open system environments. This means that we will have to 
make pragmatic decisions regarding the level of our participation in the various activities. 
Unfortunately multimedia courseware and open system activities are distributed over a 
number of different standards and related forums. Fortunately NIST already participates 
in most of the appropriate activities. We will need to coordinate that participation with 
respect to multimedia courseware to effectively represent federal agency requirements 
for standards. The major challenge is to locate the appropriate venues for national and 
international acceptance of the work r'^lated to multimedia courseware. Our knowledge 
of this arena will help us find the appropriate venues which we can work to accelerate 
international standards. 

In addition to the standards related activities, we have also been working to broaden the 
visibility of the multimedia courseware initiative within industry and among users in both 
the government and private sectors. This effort is important if we are to establish 
collaborative partnerships for leveraging worldwide interest in multimedia courseware 
in an open systems environment. Leveraging this interest is crucial to the success of the 
Federal effort to achieve its goal to catalyze an environment in which high quality 
portable courseware is available as commercial off-the-shelf products that are competi- 
tively supplied by a variety of vendors. 
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The OSE Concept 



Extensibility 

• Based upon an architectural framework which allows an extensible collec- 
tion of interfaces, services, protocols, and supporting formats to be defined. 

Non-proprietary 

• Interface!), services, protocols, and supporting formats are defined in terms 
of non - proprietary specifications that are available to any vendor for use in 
developing commercial products. 

Consensus Based 

• Evolution is controlled by a consensus - based process for decisions regard- 
ing definition and specification of interfaces, services, protocols, supporting 
formats, and other issues- related to the computing environment. 

OSE Dimensions 

Portability 

The ability to use application software on heterogeneous hardware/software platforms. 
This includes maintainability ~ i.e. portability over time ~ perhaps the most important 
of all the open system dimensions. 

Interoperability 

The ability to have application software operating on heterogeneous hardwareAsoftware 
platforms cooperate in performing some user function and sharing data. 

Scalability 

The ability to use the same application software on many different classes of 
hardware/software platforms irom personal computers to supercomputers (extends the 
portability concept). 
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The OSE Framework 



APPLIC/OTON SOFTWARE 



OPERATING 

SYSTEM 

SERVICES 


USER 

INTERFACE 
SERVICES 


PRCXJRAMMING 
SERVICES 


DAIAMG^fr 
SERVICES 


DADV 

INTRCHG 

SERVICES 


GRAPHIC 
SERVICES 


NETWORK 
SERVICES 



HARDWARE / SOFTWARE PLATFORM 
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OSE Services 



Operating System Services 

Kernel Operations 

Commands & Utilities 

System Administration 

Operating System Security 
User Interface Services 

Client-Server Operations 

Object Definition & Management 

Window Management 

Dialogue Support 

User Interface Security 
Programming Services 

Programming Languages and Bindings 

Integrated Software Engineering Environments and Tools 

Progranmiing Security 
Data Management Services 

Data Dictionary/Directory 

Database Management System 

Distributed Data 

Data Management Security 
Data Interchange Services 

Document Interchange 

Graphics Data Interchange 

Product Data Interchange 

Data Interchange Security 
Graphics Services 

Two- and Three-Dimensional Graphics Support 

Graphics Database Support 

Graphics Programming and Data Security 
Network Services 

Data Communications 

Transparent File Access 

Personal/Micro Computer Support 

Distributed Computing 

Network Security 
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APPENDIX B 

THE APPLICATIONS PORTABILITY PROFILE 

(APP) 
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A Profile 

A suite of specifications describing the functionality required to accommodate a specific 
class of applications. 

Developing a profile involves: 

• Identifying required services and interfaces 

• Choosing among alternative specifications 

• Tailoring the specifications 

• Augmenting the specifications 

TheAPP 

An OSE profile developed to meet the application needs of the U.S. Federal Govern- 
ment. The APP specifications have been tailored to enhance portability and inter- 
operability of U.S. Federal 

• Software 

• Systems 

• Personnel 

• Data 




ITie U.S. Federal OSE Profile 
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The APP Project 

The APP project is guided by 

• A concern for timeliness 

• A commitment to voluntary standards 

• A need for an architectural framework 

The APP project will produce 

• Planning Guidelines to help agencies develop strategies to realize the 
benefits and minimize the risks of open system environments 

• Usage Guidelines to help agencies deal with issues involved with the im- 
plementation and migration of open system environments 

• Technical Specifications that provide guidance to buyers of open system 
products and services 

When International Standards are not available for use as the basis for APP specifica- 
tions, NIST will use the following order of precedence to select from among alternative 
sources for specifications 

• U. S. national standards (e.g. IEEE Std 1003.1 -1988) 

• U. S. national standards committee work in progress (e.g. IEEE P1003.2 
Draft 9) 

• Other federal standards (e.g. DoD Standards) 

• Specifications that are publicly available and for which implementations are 
commercially available from a variety of sources (e.g. X Window System, 
Version 11) 

In selecting specifications, NIST will 

• Use specifications that reflect an appropriate level of maturity, stability, and 
consensus 

• Take steps to ensure that our actions are consistent with the direction being 
taken within the formal standards arena 

• Establish an open process for an orderly migration to international stand- 
ards as consensus evolves in the national and international conmiunity 
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Evolution of the APP 

At any moment in time specifications for individual components of the APP will be at 
different points along a continuum of maturity, stability, and consensus 

NIST has established an open process to ensure that the APP reflects the evolving 
consensus of the national and international community 

Both users and vendors are encouraged to become involved in this process through 
participation in an ongoing series of NIST sponsored APP workshops 

These workshops provide a forum for communicating information and obtaining feed- 
back on the evolving APP 

• User workshops address issues of special concern for those interested in 
using APP specifications in procurement 

• Implementors workshops address issues of special concern to those inter- 
ested in building products to the evolving APP specifications 



Current APP Specifications 

In examining APP specifications, it is important to keep in mind that 

• Many of the specifications have not yet evolved into national or internation- 
al standards 

• A significant number of the specifications have already been adopted as FIPS 

• Some of the specifications reflect standards work in progress 

• Some of these specifications may not be appropriate for the PORTCO en- 
vironment 
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APP Specifications 

Operating System Services 

Kernel Operations - (POSIX) FIPS 151-1 

Commands & Utilities - P1003.2- Proposed FIPS 

Systems Administration - P1003.7 

Security - P1003.6 
Data Management Services 

Data Dictionary/Directory (IRDS) FIPS 156 

Query/Reporting (SQL) FIPS 127-1 
Graphic Services 

Display Element Definition & Management - (GKS) FIPS 120 

Graphic Object Attribute Definition & Management - (PHIGS) FIPS 153 
Data Interchange Services 

Documents 

- SGML -FIPS 152 

- ODA/ODIF- ISO/IS 8613 
Graphic Data - (CGM) HPS 128 

Product Descriptions - (IGES) NBSIR 88-3813 
Network Services 

Data Communications - (GOSIP) - FIPS 146 

Transparent File Access - P 1003.8 

Remote Process Execution - P1003.8 
User Interface Services 

Client-Server Operations (XWindow System) FIPS 158 

Object Definition & Management (XWindow System) FIPS 158 

Window Management - P1201 

Dialogue Support - P1201 
Programming Services 

Languages 

- ADA -FIPS 119 

- C-X3.159-1989 

- COBOL -FIPS 021-3 

- FORTRAN - FIPS 069-1 

- PASCAL - FIPS 109 
CASE Environments & Tools 

Library Support 
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The National Computer Systems Laboratory 

CoiHiJuters have transformed the way the government does business. Computer systems 
offer the potential for increasing productivity, for solving problems, and for rapidly 
sharing information through networks. However, barriers still exist to the efficient use 
of computers, to the cost-effective exchange of information, and to the protection of 
iiiformation in computer systems from threats of all kinds. 

At the National Institute of Standards and Technology (NIST), the National Computer 
Systems Laboratory (NCSL) responds to these challenges in many ways, developing 
standards and test methods, conducting research on computers and related telecom 
munications systems, and providing technical assistance. Our activities support key goals 
of the federal government for the 1990s: improved management of resources and 
delivery of timely and cost-effective services to the public. 

To achieve these goals, our laboratory-based research activities advance the efficient use 
of computer technology and support the development of off-the-shelf, commercial 
products for computer system users. Technology transfer to federal agencies completes 
the research cycle. 

NCSL consults with federal agencies to solve technical problems. Carried out on a 
cost-reimbursable basis, projects are selected for their broad applicability to federal 
agency information processing and their contributions to our programs. Our profes- 
sional staff is uniquely qualified to address technical problems in computer security, 
software engineering, advanced computer systems, database management and graphics 
systems, and distributed processing. 

Information Systems Engineering Division 

The Infcnriv^tion Systems Engineering Division supports standards development and 
provides technical assistance to government and industry in: 

• data administration, 

• data management, 

• computer graphics, 

• geographic information systems, 

• standards validation, and 

• programming language technologies. 

For the past several years, NCSL has actively contributed through research and technical 
assistance to the Computer-aided Acquisition and Logistic Support (CALS) initiative of 
the Department of Defense (DoD). Introduced in 1985, this program seeks to reduce 
costs and improve the quality of all major DoD weapons systems acquired in 1990 and 
beyond. 

To achieve these goals, NCSL assists DoD in selecting and implementing standards for 
the exchange and storage of digital data. One example is the Computer Graphics 
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Metafile (CGM) standard which is used by CALS to pass graphical pictures among 
ditferent computers and graphical devices in t' .e development of technical manuals. 

A research initiative resulted in the Information Resource Dictionary System (IRDS) 
standard and our IRDS prototype, a software system that records, stores, and processes 
information about an organization's data and data processing resources. The IRDS 
enables federal government users to imprce productivity by identifying information 
resources that can be shared within an organization and between organizations. There 
are now over 90 users of our IRDS prototype in federal agencies, private industry, 
academia, and several foreign countries. 

Often the work which we do for one federal agency furnishes long-term benefits to many 
agencies. One example is the assistance NCSL provided to the National Archives and 
Records Administration in developing an Archives policy for the preservation of 
electronic records. The policy provides for the safe and efficient transfer of database 
information, graphics, text, and technical documents of historical value from the creating 
agencies to the National Archives for safe-keeping and availability to historians. 

Systems and Software Technology Division 

Providing assistance to federal consumers of commercial information system products 
and services is the goal of this Division. 

Working with vendors, users, and voluntary standards organizations, NCSL advances the 
development and implementation of standards for improved software quality and infor- 
mation ex( iiange. One example is the standard on Portable Operating System Interface 
for Computer Environments (POSIX), Federal Information Processing Standard (FIPS) 
151-1. POSIX promotes portability of software applications. Federal agencies benefit 
with reduced costs and increased flexibility when the standard is used to acquire 
computer systems. 

The ability to move or port an application from one operating system environment to 
another is important for cost-effective computing. NCSL is working with users and 
industry to define and implement the Applications Portability Profile (APP), a group of 
standard elements including database management, data interchange, network services, 
user interfaces, and progranmiing services. We sponsor workshops for vendors and users 
to explore common ways to implement the standards that are being developed. 

NCSL is a recognized leader in the development of standards and guidelines on software 
engineering topics including: 

• software design and testing; 

• software maintenance; 

• fourth-generation languages; and 

• evaluation and acquisition of software. 

In the past our Electronic Publishing Laboratory has assisted federal agencies in the 
selection and use of publishing systems by demonstrating the capabilities and limitations 
of different publishing technologies. More importantly, the laboratory supported the 
development of document processing standards such as the Office Document Architec- 
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ture (ODA) and Standard Generalized Markup Languajge (SGML). Currently the lab 
supports the development of the Standard Page Description Language (SPDL). This 
laboratory also supports our research in document architectures, multimedia, and hy- 
pertext . Our iavQlvement in these emerging technologies enables us to assist agencies 
in implementing standards in the office environment. 

Computer Security Division 

Computer systems and the information they process are valuable and critical assets of 
an organization. The Computer Security Division develops standards and guidelines for 
cost-effective security measures in computer systems throughout government and in- 
dustry. 

Under the Computer Security Act of 1987, NCSL is the lead agency for standards, 
guidelines, and technology for information security throughout the federal government 
(excluding classified, national-security-related systems and information). Computer 
security standards are important because they provide both users and vendors with 
technically effective methods for protection and industry-wide interoperability. Our 
Computer Security Program has four primary components: 

Security Technology. Effective use of computer security technology helps assure 
reliable, low-cost protection. Among the areas which NCSL addresses are personal 
identification technology, cryptography. Secure Operating Systems, personal com- 
puter security, database security, and network security architecture. 

Management and Evaluation. Effective computer security requires technical, physi- 
cal, and management controls, based on an assessment of the tradeoffs between risks 
and control costs. NCSL develops guidance in the application of risk management 
techniques, computer security management, contingency planning, and audit. 

Planning and Assistance. The Computer Security Act designates NCSL to provide 
federal agencies with advice and assistance in computer security planning, training, 
and related activities. With the National Security Agency, NCSL reviews and com- 
ments on agency security plans for sensitive, unclassified systems. Regular 
workshops, meetings, and a national computer security conference comprise our 
ongoing program to facilitate the interchange of ideas, needs, guidance, and stand- 
ards. 

Research and Development. An ongoing technical research and development pro- 
gram ensures that the needs and opportunities offered by new technology are used 
in the development of standards and guidelines. Research is conducted in personal 
identification technologies, computer viruses, network security mechanisms, operat- 
ing system security, cryptography, and related areas. 

Systems and Network Architecture Division 

The development and standardization of Open Systems Interconnection (OSI) technol- 
ogy, formal methods for test systems, and integrated, interoperable network manage- 
ment technology are the focus of this Division. 

NCSL has been actively supporting the standardization of OSI technology for over ten 
years. Approved in 1988 as Federal Information Processing Standard (FIPS) 146, the 
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Government Open Systems Interconnection Profile (GOSIP) defines a common set of 
data communication protocols which enable systems developed by different vendors to 
interoperate and enable the users of different applications on these systems to exchange 
information. 

Effective in 1990, the initial version of GOSIP will assist federal agencies in acquiring 
computer systems that support electronic mail and file transfer applications over a variety 
of local-and wide-area networks. Future versions of GOSIP will include additional 
applications, such as virtual teiminal, security, office document interchange, directory 
services, and dynamic routing. 

NCSL is in a unique position to provide technical assistance to other federal agencies to 
support the implementation of GOSIP. One example is our recent work for the Defense 
Communications Agency. We completed the initial phase of the OSI directory prototype 
implementation; connecting the prototype directory to the NCSL-developed Depart- 
ment of Defense/OSI electronic mail gateway successfully demonstrated the practical 
application of the protocols. 

NCSL also supports private industry through testing and standards implementations 
activities. For example, we established OSINET, a cooperative goverrmient/industry 
research network which tests commercial OSI products for interoperability. 

As the success of OSI creates large, multi-vendor networks composed of many com- 
ponents, the need for integrated, interoperable network management becomes critical. 
To respond to the needs of users and vendors over the next five years, NCSL has 
developed a program to advance the standards necessary for effective integrated network 
management. 

Advanced Systems Division 

Division staff has expertise in parallel processing performance, data storage technology, 
distributed systems, automated recognition methods, and Integrated Services Digital 
Networks (ISDN). 

Research focuses on economical methods of instrumentation that minimally perturb 
parallel processors and the design of coherent evaluations that reliably characterize the 
machines. Supported by the Defense Advanced Research Projects Agency (DARPA), 
NCSL developed the Trace Measurement System (TRAMS), a hybrid measurement tool 
used to obtain trace measurement information. Govenmient and industry will benefit 
from this feasible and economical approach to providing measurement capabilities to a 
wide range of multiprocessors. 

Under an interagency agreement with the National Archives and Records Administra- 
tion, NCSL is developin- a testing methodology that predicts life expectancy of optical 
disk media. This researc i will assist goverimient managers in plarming how long infor- 
mation may safely be stored on these media. 

Our continuing research in automated recognition technology supports the work of 
several federal agencies. One example is our work for the Federal Bureau of Investiga- 
tions to develop standards for automated fingerprint identification systems. In coopera- 
tion with academia and the private sector, our researchers design and develop test 
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procedures and speech database test materials for the DARPA Speech Recognition 
Program. 



In another research area, NCSL investigates standards and develops conformance test 
methods for ISDN. ISDN is a new telecommunications technology that makes it possible 
to send and receive voice, data, and image signals simultaneously over digital telephone 
networks. NCSL established the North American ISDN User's Forum to create a strong 
user voice in the implementation of ISDN. 
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Multimedia Courseware Project Schedule 

April 1990 - April 1992 

April 15, 1990 

RFA Announcement in the CBD and Letters Sent. 

June - October 1990 

Build Multimedia Systems Laboratory. 

June 14, 1990 

Explanation on RFA Proposal Meeting to be held at NIST. 

August 1, 1990 

Summary Proposals for Architecture are due from RFA respondents. 

August - September 1990 

Summary Proposal Analysis. 

September 1990 

Issue a report on analysis of the Summary Proposals. 

October 1990 

Government Wide Forum - Open Multimedia Laboratory; Presentations on training 
and government use of multimedia systems. Also cover CD-ROM and have SIGCAT 
attendance at Government wide forum. 

November - January 1991 

Presentation of Detailed Proposals from RFA Respondents (Two or three days of 
NIST Meetings will be sponsored). 

December 1990 

Construct overview of CD-ROM operating extension and search/retrieval (S/R) 
products. i 

January - April 1991 

Evaluation of Detailed Proposals and synthesis of preliminary standards for Portable 
Courseware. 

Januaiy 1991 

Circulate draft FIPS for ISO/IEC 9660 and ISO/IEC 10149 for comments. 
February 1991 

Conduct workshops (with SIGCAT attendance) at NIST to discuss proposed FIPS. 
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March 1991 

Preliminary Announcement of RFA results. 

Working UNIX Prototype which will run the CAMIS Courseware with a fall back 
position of running DOS through VP/ix (a LOCUS/Merge routine) on a UNIX 
Platform. 

April 1991 

RationaUzation Meeting sponsored by NIST. 

Write FIPS for ISO/IEC 9660 and ISO/IEC 10149 in Federal Register. 
June 1991 

Design conformance test strategy for CD-ROM system interoperability. (Determine 
degree of conformance testing necessary). 

July 1991 

First set of FIPS Guidelines prepared for Portable Courseware. 
August 1991 

Additional Publications (Special Pubs, Internal Reports, other appropriate publica- 
tions) relating to the Portable Courseware Architecture agreed upon and related 
conformance testing procedures. 

New Plan in place accelerating the 1991 standards identified in the Guidelines. 
Have CD-ROM implementations for developing conformance tests. 

October 1991 

Develop industry consensus on tests. 

April 1992 

Have conformance tests implemented and determine necessity of NVLAP for test- 
ing. 
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REQUEST FOR ARCHITECTURE^ 



Standards for Portable Courseware 



Abstract 

Courseware is the leading application in the 
multi-media systems domain. The evolution of a 
path for the integration and standardization of 
multi-media components is the intent of this RFA. 
It is the first step in a process to enable the 
National Institute of Standards and Technology 
(NIST) to publish a family of FIPS^ specifications 
encompassing major applications in the domain of 
multi-media. 

Purpose 

NiST is requesting architectural proposals for 
standards for portable courseware. One aspect of 
these standards will be to provide an alternative to 
the current practice of distributing courseware 
with proprietary interfaces to system services. 
Another aspect will be to specify a standard 
interchange format so that courseware developed 
on one authoring system may be modified on 
another. 

The use of portability standards will provide the 
following benefits. 



1. C siderible portions of this documeni and the general 
form have been taken from the Request for Technology for 
the Archilecture-Neuiral Distribution Formal from the 
Open Software Foundation. Several ideas and some 
wording are taken from Portable Courseware A Standard 
for Government and Industry Associates under contract to 
the Department of Defense. Other ideas and wording are 
taken from [VIA Recommended Practices for Interactive 
Video Portability , Draft prepared for the Interactive Video 
Industry Association. 

2. For the purpose of this document, courseware will be uken 
to mean computer based interactive training software. 
Although hardware has a very important role in the training 
process, this document does not directly address hardware 
standards. 

3. FIPS is an acronym for Federal Information Processing 
Standard. 



Consumers benefit by: 

• more courseware platforms available off the 
shelf. 

• increased competition among providers. 

• elimination of duplicate funding of course 
development. 

• elimination of the need to purchase 
specialized systems just for courseware* 

• a well defined evolutionary path that 
incorporates the functionality described by the 
[VIA^ Recommended Practices into an open 
systems environment. 

• preservation of investment over time and 
accommodation of future technical 
improvements. 

Providers can: 

• enjoy a greatly inaeased marketplace and 
installed base. 

• have access to previously closed markets. 

• reduce re-authoring costs by using a standard 
software interface to common system 
services. 

• be assured of a clear path for the evolution of 
architecture enhancements to open systems 
technology. 

• reduce stocking and distribution costs. 



Scope 

NIST is seeking proposed solutions to address a 
broad set of requirements affecting the creation, 
distribution, execution and procurement of 



4. IVIA is an abbreviation for the Interactive Video Industry 
Association. The tVlA Recommended Practices refers to 
the document titled ''IVIA Recommended Practices for 
Interactive Video Portability." 
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courseware. The solution should consist of: 

• A specification for a standard for courseware 
portability. (Possible examples include 
specification of virtual device interfaces^ 
(VDls) to support the common peripheral 
devices^ associated with courseware.) The 
specification should describe services 
available from the peripheral devices, e.g., for 
a graphics display, functions might include 
draw a line, draw a circle, etc. 

• A comprehensive plan and discussion of an 
evolutionary path to aUow stepwise 
refinement of the architecture to encompass 
future hardware and software technology. 

• A specification for a neutral interchange 
format for courseware so that courseware 
developed on one machine may be edited and 
maintained on another. 

• Implementation(s), if available, of one or 
more of the above. 

If complete solutions are not available, NIST 
encourages the submission of partial solutions 
that may be combined to yield a complete 
solution. Additionally, providers with partial 
solutions are welcome to group together to 
present a combined solution. 

Functional Requirements 

All candidate specifications must satisfy the 
following minimum requirements: 

Hardware Independence 

The specification should be independent of the 
host hardware architecture, i.e., the interface 
should be such that there is no recognition of 
constructs such as stack direction, word size, sign 
extension, byte order, etc. 



5. A vhlual device interface is a software mechanism that 
allows an application to use a peripheral device without 
knowledge of the hardware characteristics of thai device. 

6. Common devices might include: graphics display, video 
disc, printer, speech synthesizer, or mouse (or other 
pointing device). 



Programming Language Support 

The specification for interoperative courseware 
must support applications written in ANSf C, and 
bindings to interface functions must be specified 
as C function calls. Note: The interface 
functions themselves may require another 
language, e.g., assembly language. 

Operating Environment Concepts 

The portable courseware must be able to execute 
in the interface environment specified in FIPS 151 
(POSIX) and MS-DOS systems. In order to 
provide a framework from which contributors can 
relate specific ideas and structures, two instances 
of possible structures are presented below. The 
first example presents an MS-DOS model, and the 
second example presents an Open System 
Architecture model. 

The MS-DOS Model, Figure 1, was constructed 
from the two known MS-DOS contributions to 
portable courseware standards- The first of these 
contributions is represented by the IVIA's 
"Recommended Practices for Interactive Video 
Portability" which presents the recommendations 
of the committee for commands and interface 
mechanisms used in level three Interactive Video 
(IV) systems. The second contribution is 
represented by the Navy Personnel Research and 
Development Center's (NPRDC) "Portable 
Coureeware Architecture". This contribution 
addresses the logical control of devices over 
different device classes. It constitutes a lower 
level interface into the ove! ;i courseware model. 

The Open Systems Model, Figure 2, was 
constructed from the standard Open System 
Architecture with the insertion of an "IVIA 
Toolkit" at layer 5 in the model. This 
configuration represents one possible approach to 
incorporate the functionality of the IVIA 
Recommended Practices into an Open Systems 
environment. 

These models only deal with source language 
portability. The purpose of this RFA is to solicit 
solutions that address current and future technical 



7. ANSI is an acronym for the American National Standards 
Institute. 
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advances in all aspects of portability. 

Distributed System Support 
The technology mus* be capable of being 
distributed across a network such that new users 
can easily be added to the system without 
impacting existing users. The system should be 
able to be easily scaled to meet the needs of one 
user to many thousands of users. 

Extensibility 

The technology must be extensible to allow for 
new devices. 

Image Management 

The portable courseware system shall provide a 
means of managing a variety of images, including 
video, raster, vector graphics, and page 
description language. 



Key Evaluation Criteria 

Submissions should provide for a high level of 
portability and functionality. In addition, the 
following evaluation criteria will be used: 

Courseware Quality 

The submissions should support courseware of the 
quality and functionality used by the federal 
government. Specifically, they should include a 
i:tatement, with appropriate justification from the 
submitter, that the proposed system can support 
courseware of the quaiUty required by the federal 
government both now and in the foreseeable 
future. 

Standards 

Besides the FIPS 151 and ANSI C standards 
already referenced, submissions should conform 
to existing (or emerging) HPS, ANSI, or ISO^ 
standards wherever possible. 

9 Architecture Evolution 

As noted in Attachment 1, the I VIA 



8. ISO is an abbreviation for the International SUndards 
Organization. 



Recommended Practices functionality is the 
baseline for the evolution of the architecture in a 
logical progression; all architectures must provide 
a mechanism for upward movement from the 
baseline functionality. 

Product Readiness 

An implementation of the proposed specification 
must be available by January, 1991. 

Documentation 

Submissions shall provide clear, accurate^ and 
usable product documentation of the 
specification(s) at the interface and interchange 
level. Documentation should include any known 
limitations. Additionally, it should be available in 
machine readable source format. The source 
should be in a portable interchange format such as 
in AAP SGML tags^ or should be easily 
transformable to such format by the submitter. 

General 

Consideration will be given to other criteria such 
as ease of use, breadth of applicability, functional 
richness and innovation. 



Evaluation Process and Milestones 
St4)ge 1 

NIST will conduct a meeting on June 14, 1990, to 
explain -ts goals and the RFA process. 

Stage 2 

Notification of intent to respond is required by 
August 1, 1990. The notification must be 
accompanied by a summary proposal that will be 
reviewed by NIST staff to allow preparation for 
the evaluation phase. Additionally, NIST may 
contact submitters so that they can improve the 
quality of their submissions. Feedback to the 
submitters will be provided by September 1, 
1990. 



9. American Association of Publisiiers Electronic Manuscript 
Scries: Standard for Electronic Manuscript Preparation 
and Markup, 



ERLC 



Page 51 



stage 3 

Detailed proposals must be received by October 
1, 1990. At that time, an evaluation team 
consisting of NIST staff, industry and academic 
consultants will review submissions according to 
the requirements of this request. Submitters of 
qualifying technologies will have an opportunity 
to present their material to NIST in November, 
1990. 

The evaluation team will then select a group of 
technologies to participate in the proof of 
feasibility phase that will begin in January, 1991. 

Stage 4 

A final group of technologies will be selected by 
the evaluation team after feasibility has been 
shown. This group of submitters will be involved 
in the final evaluation phase that will include a 
lab trial at NIST. 

NIST will announce the selected technologies 
along with the selection rationale in April, 1991. 

If no submissions meet the requirements of this 
request for architecture, then NIST will consider 
modifications to the request not later than April, 
1991. 



What to Submit 

Siunmary Proposals 

Excluding figures, charts, etc., summary proposals 
should be no more than 10 pages in length 
(excluding figures, charts, photos, etc) and should 
include a response to each of the requirements 
stated in this document. Summary proposals 
should also contain a discussion relating to each 
of the key evaluation criteria, and an outline of 
the architecture. 

Detailed Proposals 

Detailed proposals should include: 

1. A specification for an architecture for 
courseware portability and/or u 
specification for a neutral interchange 
format for courseware. 

2. A detailed and complete description of the 
proposed implementation and 



demonstration. 

3. A proposed documentation plan. 

4. For submissions that include an actual 
implementation, documentation for using 
the implementation on two or more 
different hardware platfonns should be 
provided. 

5. A statement of the cost benefit for the 
federal government if this technology is 
chosen. 

6. Any other materials the submitter deems 
relevant to this evaluation process, such as 
internal documentation, source code, 
functional specifications, etc. 



How to Submit 

Send submissions to: 

Chief, Systems and Software Technology Division 
National Institute of Standards and Technology 
Building 225, Room B266 
Gaithersburg, Md. 20899 

Attn: Portable Courseware Project 

Questions concerning this Request for 
Architecture should be directed to: 

Dr. Larry Welsch 

National Institute of Standards and Tedinology 
Systems and Software Technology Division 
Building 225, Room B266 
Gaithersburg, MD 20899 
(301)975-3345 

Attn: Portable Courseware Project 
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Attachment 1 



Introduction to 



Portable Courseware Standards 



April 17, 1990 



National Institute of Standards and Technology 



er|c 4 



Portable Courseware Standards 



Preface 

This document provides an overview of the concept of portable courseware. It is intended 
to answer basic questions concerning purpose and function. The accompanying Request 
for Architecture should be consulted for specific technical requirements. 

Introduction 

The National Institute of Standards and Technology (NIST) is soliciting proposals to 
define and implement standards for portable courseware^^ Portable courseware will be 
interoperable on a variety of hardware platforms and portable courseware developed on 
one authoring system will be maintainable on others. 

The goal of this program is to achieve current and future interoperability, compatibility, 
interchangeability, and modularity for federal courseware. This should be true not only 
for common systems but across processors, architectures, and peripheral devices. 
Courseware portability can be achieved by establishing software interface and interchange 
standards to be used for federal courseware. 

What problems will portable courseware solve? 

Several commercial manufacturers offer high-performance, low-cost, interactive training 
hardware, but bundle these products with proprietary software interfaces. Because of 
these proprietary interfaces, courseware developed for these machines is not portable to 
others without expensive reprogramming. Additionally, differences in operating system 
interfaces such as those between MS-DOS™ and POSIX interfere with courseware 
portability. 

A second problem concerns the authoring and maintenance of courseware. There are 
several software tools to assist courseware development. These tools, commonly known 
as 'authoring systems', allow non-programmers to develop courseware by interacting 
with sophisticated menus and forms, or by using courseware specification languages. 
Using these authoring systems may substantially reduce the costs of courseware by 



10. SevenI ideas and much of the wording for this documeni were ulcen from Portable Courseware A Standard for Government and 
Industry prepared by Systems Eagiaeeriag Associates under contract lo Ihr Department of Defease. The general form of the 
docnmeal and some of the wording were Ul(ea from the document, Introduction to the Concept of the Architecture— Neutral 
Dbtribution Format, April 25, 1989 of the Open Software Foundation. 

11. For the purpose of this document, courseware will be uken to mean computer based interactive trkising software. Although 
hardwai^ his a very imporUnt role ia the tniaing process, this document does not directly address hardware sundards. 



Page 57 



minimizing the participation of high-priced programming staff during the development 
cycle. Unfortunately, courseware developed on one authoring system often cannot be 
modified on another. 

Courseware development and maintenance costs increase dramatically with changes in 
hardware, operating system, or authoring tools. Advances in hardware and software 
technology and market pressures encourage each of these key system components to 
evolve, so the costs of developing and maintaining courseware are high. Standards are 
needed to insulate courseware from changes in these underiying system components. 

How will portable courseware standards solve these problems? 

Portable courseware standards will solve the problems associated with variations in 
hardware and operating systems by defining standard interfaces, i.e., courseware and 
authoring systems will not directly interact with hardware or the operating system but will 
instead bind to these via standard interfaces. In particular, POSIX (with possible 
extensions) will provide the operating system interface, X-Windows will provide the 
graphical interface, ANSI C will be the interface definitiotP language, and other 
standards (such as those for CD-ROM, etc) may be needed. 

The problem of authoring system independence will be addressed by defining a standard 
interchange format that allows for the presentation features, control flow, etc. available in 
popular federal and commercial systems. Where possible, data interchange standards will 
be used to represent text, graphics, audio, etc. The definition of an interchange format 
that provides true authoring system independence will be challenging but very cost 
effective once it is complete. 

All standards that are defined to support portable courseware must be easily extensible to 
support the new technologies that will become available over the next few years. 

What work has been done to date? 

Known work in the arena of portable courseware standards has focused primarily on MS- 
DOS based systems. In that regard, contributions are currently available from two 
organizations. They are the Interactive Video Industry Association (IVIA) and the Navy 
Personnel Research and Development Center (NPRDC). IVTA is a non-profit 
organization whose members are companies actively involved in courseware hardware, 
software, and systems. NPRDC is the Navy's manpower and personnel laboratory, and < 
has been designated by DOD as the main point of contact on Portable Courseware issues. 



12. The poiuble courseware architecture will be specified in ANSI C. This will not constraic the language that programmers use to 
write courseware applications. 
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Documentation on these contributions should be solicited from the principals. The I VIA 
contribution provides a high level command and interface mechanism functionality. The 
NPRDC contribution addressed the logical control of devices over different device classes 
and constitutes a lower level interface defintion. To this end, the Department of Defense 
(DOD) has adopted the IVIA application interface specification for training systems. 

Interactive Video Industry Association 
Techworld Plaza, Suite 440 

800 K Street, N.W. 
Washington, D.C. 20001 

Phone: (202) 408-1000 Fax: (202) 408-0361 



Navy Personnel Research and Development Center 

Code 15 
San Diego, CA 92152-6800 

Attn: Walter F. Thode 
Phone: (619) 353-7703 or Autovon 553-7703 

Who will benefit from portable courseware? 

The use of standards for portable courseware should provide the following benefits: 

Consumers benefit by: 

• more courseware platforms available off the shelf. 

• increased competition among providers. 

• elimination of duplicate funding of course development. 

• elimination of the need to purchase specialized systems just for courseware. 

• a well defined evolutionary path that incorporates the IVIA^^ standard's functionality 
into an open systems environment. 

• preservation of investment over time and accommodation of future technical 
improvements. 



13. IVIA is an abbreviation for liie Inieraciive ideo Industry Association. The IVIA 'sundard' refers to the document titled "IVIA 
Recommended Practices for Interactive Video Portability." 
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Providers can: 



• enjoy a greatly increased marketplace and installed base. 

• have access to previously closed markets. 

• reduce re-authoring costs by using a standard software interface to common system 
services. 

• be assured of a clear path for the evolution of architecture enhancements to open 
systems technology. 

• reduce stocking and distribution costs. 

Why is the federal government addressing the problems of portable 
courseware now? 

The reasons for addressing portable courseware standards are economic and practical. By 
providing courseware interoperability, the costs associated with converting courseware to 
execute on different hardware will be eliminated. Additional savings will result from not 
having to buy the specialized systems that are commonly required for courseware. 
Finally, more savings will result from economies of scale. The wider availability of 
courseware will result in better prepared civilian and military staff. 
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